Skip to content
This repository has been archived by the owner on Mar 5, 2025. It is now read-only.

Fix incorrectly versioned bn.js type export (#4418) #4437

Merged
merged 3 commits into from
Oct 8, 2021

Conversation

spacesailor24
Copy link
Contributor

Took over the original PR to make some changes

* fix incorrectly versioned bn.js type export

Signed-off-by: Matt Rice <[email protected]>

* WIP

Signed-off-by: Matt Rice <[email protected]>

* WIP

Signed-off-by: Matt Rice <[email protected]>
@spacesailor24 spacesailor24 added the 1.x 1.0 related issues label Oct 7, 2021
@spacesailor24 spacesailor24 self-assigned this Oct 7, 2021
@render
Copy link

render bot commented Oct 7, 2021

@spacesailor24
Copy link
Contributor Author

spacesailor24 commented Oct 7, 2021

Oh I think I'm wrong about including @types/bn.js as a dev-dependency

In this particular case, we want to provide users with the specific version of the types so that type mismatches don't occur

@spacesailor24 spacesailor24 marked this pull request as ready for review October 7, 2021 01:52
Copy link
Contributor

@nazarhussain nazarhussain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per the change log we have very minimal change.

@types/bn.js as dev-dependency to additional packages (notably web3-utils)

But the files which are changed are 27, Is there a possibility to only include required changes in this PR. And if there is any other package update we can create specific PR for it.

@spacesailor24
Copy link
Contributor Author

@nazarhussain

As per the change log we have very minimal change.

@types/bn.js as dev-dependency to additional packages (notably web3-utils)

But the files which are changed are 27, Is there a possibility to only include required changes in this PR. And if there is any other package update we can create specific PR for it.

The files changes are all updates to package.json and package-lock.json (minus CHANGELOG.md). Updating these files all at once, and not trying to discern what package-lock.json changes are bare minimum necessary, is the easiest way to avoid breaking something, imo

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
1.x 1.0 related issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants